ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group94b.txt/000039_icon-group-sender _Sun Sep 4 22:02:07 1994.msg

Internet Message Format | 1995-02-09 | 4KB

Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 15:28:08 MST
To: [e-mail]
Date: Sun, 4 Sep 1994 22:02:07 GMT
From: [e-mail] (Richard L. Goerwitz)
Message-Id: <[e-mail]>
Organization: University of Chicago
Sender: [e-mail]
References: <33vlde$[e-mail]>, <[e-mail]>, <347vun$[e-mail]>
Reply-To: [e-mail]
Subject: Re: Icon - still alive??
Errors-To: [e-mail]

In article <347vun$[e-mail]> [e-mail] (Nick Williams) writes:
>
>What was Icon intended for then? Is it supposed to allow highly portable
>programming by putting huge restrictions on what Icon programmers can
>do? I bet not (why else would there be a preprocessor?, or &features for
>that matter?). Frankly, Icon needs better access to system dependent
>features...

Your opinion is a valid one, and shared by others.  I just don't happen
to agree.  We are going in circles here, in a sense, because my answer
to what you are saying now is the same answer I gave before:  If you need
system-dependent features, improve Icon's access to facilities that deal
with them.  To extend Icon here and there to make it more PERL-like or
more C-like will fritter away the language.

As I pointed out before, Icon has an improved C calling interface that
allows you to dynamically load functions into the run-time system.  So
all you have to do to call a C function is to put it into a dynamically
loadable library, and load it from your Icon program.  No recompilation
of the Icon source is needed.  I like this.  There are even some exam-
ples in the new documentation for Icon 9.0.

>Forcing programmers to go hack the RTL code from which icont and iconc
>are made or to write C function wrappers to system routines (plus Icon
>wrappers as well), then relink the relevant libraries and executables
>(or use loadfunc()) just to make them think twice before they use a
>system dependent function is CRAZY!

Again, I just don't agree.  If loadfunc() isn't elegant enough, then an
improved interface should be developed at some point.  In theory it is
nice to have a language be all things to all people.  But once a lang-
uage comits to this philosophy, it's hard to know when to stop.  And the
result can be ugly and messy.  Far uglier and messier than loadfunc() -
for which there is perfectly good sample code in the Icon docs.

>Indeed, and why are they putting in graphics extensions? because they
>are *useful* to have (though _I_ don't use them often); the same would
>apply to adding fork(), exec() and the like (system() is portable, but
>limiting, not to mention dangerous).

Here's a prime example.  Creation of a new process in Unix is not atomic.
You have to copy the current process, then overlay it.  This is pretty
system dependent.  You mentioned setenv() above.  I don't believe that
the Mac has environment variables per se.  Getenv() is marginally useful
for passing information about the environment to Icon (e.g. if you want
to know what TERM type you have under Unix).  I've never needed setenv()
within Icon, myself, though.  Not so say someone wouldn't.  But then I
could see how almost every platform-specific facility might be useful
at one time or another.  That doesn't mean I want to see them as part
of the core Icon language definition.

To back off a moment, let me just repeat that your opinion is perfectly
reasonable, and I'm sure many others share it.  There's another side,
though, and that's the one I happen to be on.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]          rutgers!oddjob!ellis!goer